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1. Current Problems 
Current driver model designed in late 90 by XFree86 


First Release in 2000 


Design goal: let the driver control any aspects of the configuration. 
“Move common code to optional helper functions. 
O Inherited limitiatons from mi and ?fb layers and core protocol. 


Supported hardware of the late 90’s: 
OSingle analog display output with 
Cdepth 8, 16, 24 
02D acceleration 


1. Current Problems [cont.] 


Feature: was able to operate several independent graphics chips. 


Later added: 

OXV video scaler support 

CO Support for multiple (2) display outputs with independed CRT 
controller 


2. Limitations and Problems 
“Multiple output devices per chip 


Multiple types of output devices: 
OAnalog (VGA style) 
ODVI (digital) 
OVideo bridges (TV) 


JMode selection too simplistic: drivers do their own 


OMissing hot plug support for output devices 


“Limited support for switching output channels on the fly 


2. Limitations and Problems [cont.] 


OMany features not configurable ‘on the fly’. 


Oin general: ‘Code is cheap!’ - register bit banging is not! 


OX is not alone: other software needs mode setting, too! 
OText console 
Ostandalone DRI 
OXgl 


2. Limitations and Problems |[cont.] 


ONo support for hotplugging graphics devices bootstrap procedure 
makes it impossible to add devices on the fly: 


OProbe() 
OPrelnit() 
OScreenlnit() 


02D accel model not suitable for RENDER 


“Modern video drivers consist of drivers for different components 


Ono clear driver internal interfaces 
OMigration to new driver model difficult 


3. A Model for the Future 


O Take driver out of the Xserver 
Ocreate a separate video output driver module/project 


Oprovide library/daemon: daemon record information about the driver/HW state, 
library to provide interface to applications (like Xserver),perform that change hw 


state (mode etc), provide a low level 2D acceleration, video scaler etc. 
functionality. 


OLet Xserver take ‘passive role’: 


OMode selection happens between a UI and the driver.Pass video mode 
information to Xserver to adjustitself to underlying mode. 


“Create a thin DDX that to interface with driver API to take mode 
information. 


4. How to get there? 


ONot possible in a single step 
“Preparations to be made in existing structure. 


Phase 1 


OLook thru DDX: migrate HW related code (bus, address range 
mapping into a separate layer. 


4. How to get there? [cont.] 


OAs a driver maintainer 
Oldentify different driver components (mode setting, 2D acceleration,DRI, video 
...) and understand their interrelations. 


Oldentify which parts communicate with the other layers of X (Prelnit(), 
Screeninit()) Video, XAA, DRI ... 


“Separate X specific parts functionally from driver internal code. 
Create well defined driver internal interfaces 


“Modify drivers to implement these interfaces 


O Identify driver components that can be share between drivers 
(RAMDAC, Video and FP bridges etc) 


4. How to get there? [cont.] 


“Provides opportunity to clean up drivers and ‘discover ‘junk code’ 


"Easy to do for drivers that are currently maintained. 


OWhat do we do about unmaintained drivers? 
Olf they are simple enough it may be easy to do. 


OPossible to do without special knowledge if hardware for testing is available. 


OWe may loose some drivers. 


4. How to get there? [cont.] 
Phase 2 


“Define external API for external library 


“Add interfaces to sofware to work with this new DDX: 
For Xserver: prepare DDX to work with this 


“Migrate selected drivers 


£O Test software (new Xserver DDX) with selected drivers 


4. How to get there? [cont.] 
Phase 3 


“Port over the remaining drivers 


